What is this field? It's not included in the original proposal. The "units_traveled" value mentioned in the spec doc is just a place-holder variable that refers to a computed value from the actual trip itinerary (distance traveled in km, zones, etc)

Is your suggestion that shape_dist_traveled is used for this? Given that these things never line up with operator values, my interpretation was that you would give a origin_id and destination_id and mention the number of units_traveled. In such way it would be possible to unambigiously port a A/B matrix into GTFS.

Well, the distance calculation depends on the distance_mode enum:

1 - per-km - distance values will be computed by computing the length of the shape between the two stops. shape_dist_taveled values will be ignored (since they are unit-less) but instead the distance between lat-lon points belonging to the shape will be computed directly. This is necessarily a bit approximate, but should hopefully give the rider a reasonably close value.
2 - per-zone - compute the number of zones traversed by an intinerary
3 - per-stop - compute the number of stops traversed by an itinerary

I'm not sure it makes sense to include a "units_traveled" for each pair of origin_id and destination_id values. If you are going to be including the entire stop-to-stop fare matrix in the GTFS, why would you need distance-based pricing at that point? You could just specify the price as a fare_attribute directly.

This 'approximate' will not work for many agencies. Firstly because some do not even publish shapes, secondly because the shape distance is not used in fare calculation, thirdly rounding errors.

The main reason why we can't publish the price is because of a "startup cost" encoded in "price". The distance-based price is a surplus to that.

Can you describe when "startup cost" is used? If I take a trip from A=>B, with a transfer, followed by B=>C, do I pay the startup cost for the entire trip or just the first leg?

Considering that you are using the same fare system, only the first leg given that your transfer is, within the transfer_duration period.

In the current allows to describe linear relations with respect to distance traveled, but not degenerative relations. The latter (Dutch Railways) we did implement with a cross-product operation on all stops.

In that case, I'd propose the following:

Introduce an additional "distance_mode" enum value:

4 - user-defined distance unit is used, as defined in fare_distances.txt

And introduce a separate fare_distances.txt file with fields:

from_zone_id, to_zone_id, distance_traveled

which would be used to define the A/B matrix of distances.

The main issue here is that I think of fare_rules.txt as defining rules for matching legs and itineraries, while distance_traveled is more of a property of a leg to be matched.